As is known, and referring now to FIG. 1, a digital rights management (DRM) and enforcement system is highly desirable in connection with digital content 12 such as digital audio, digital video, digital text, digital data, digital multimedia, etc., where such digital content 12 is to be distributed to users. Upon being received by the user, such user renders or ‘plays’ or otherwise accesses the digital content with the aid of an appropriate rendering device or the like such as a media player on a personal computer 14 or the like.
Typically, a content owner distributing such digital content 12 wishes to restrict what the user can do with such distributed digital content 12. For example, the content owner may wish to restrict the user from copying and re-distributing such content 12 to a second user, or may wish to allow distributed digital content 12 to be played only a limited number of times, only for a certain total time, only on a certain type of machine, only on a certain type of media player, only by a certain type of user, etc.
However, after distribution has occurred, such content owner has very little if any control over the digital content 12. A DRM system 10, then, allows the controlled rendering or playing of arbitrary forms of digital content 12, where such control is flexible and definable by the content owner of such digital content. Typically, content 12 is distributed to the user in the form of a package 13 by way of any appropriate distribution channel. The digital content package 13 as distributed may include the digital content 12 encrypted with a symmetric encryption/decryption key (KD), (i.e., (KD(CONTENT))), as well as other information identifying the content, how to acquire a license for such content, etc.
The trust-based DRM system 10 allows an owner of digital content 12 to specify license rules that must be satisfied before such digital content 12 is allowed to be rendered on a user's computing device 14 and also during usage of such content 12. Such license rules can include the aforementioned temporal requirement, and may be embodied within a digital license 16 that the user/user's computing device 14 (hereinafter, such terms are interchangeable unless circumstances require otherwise) must obtain from the content owner or an agent thereof. Such license 16 also includes the decryption key (KD) for decrypting the digital content, perhaps encrypted according to a key decryptable by the user's computing device, and is signed by the license issuer. Because the content 12 requires the license 16 for access thereto, then, the content 12 may be freely distributed. Significantly, the license 16 must somehow be bound either directly or indirectly to a computing device 14 on which the content 12 is to be rendered. Otherwise, the license 16 could potentially be copied to an infinite number of other devices 14 to render the corresponding content 12 thereon, also.
The content owner for a piece of digital content 12 must trust that the user's computing device 14 will abide by the rules and requirements specified by such content owner in the license 16, i.e. that the digital content 12 will not be rendered unless the rules and requirements within the license 16 are satisfied. Preferably, then, the user's computing device 14 is provided with a trusted component or mechanism 18 that will not render the digital content 12 except according to the license rules embodied in the license 16 associated with the digital content 12 and obtained by the user.
The trusted component 18 typically has a license evaluator 20 that determines whether the license 16 is valid, reviews the license rules and requirements in such valid license 16, and determines based on the reviewed license rules and requirements whether the requesting user has the right to render the requested digital content 12 in the manner sought, among other things. As should be understood, the license evaluator 20 is trusted in the DRM system 10 to carry out the wishes of the owner of the digital content 12 according to the rules and requirements in the license 16, and the user should not be able to easily alter such trusted element for any purpose, nefarious or otherwise. Of necessity, the trusted component 18 has knowledge of the external entities trusted to issue licenses and can certify the identity of various entities such as the external entities, users, applications, and machines.
As should be understood, the rules and requirements in the license 16 can specify whether the user has rights to render the digital content 12 based on any of several factors, including who the user is, where the user is located, what type of computing device the user is using, what rendering application is calling the DRM system, the date, the time, etc. In addition, the rules and requirements of the license 16 may limit the license 16 to a pre-determined number of uses, plays, or pre-determined play time, for example.
The rules and requirements may be specified in the license 16 according to any appropriate language and syntax. For example, the language may simply specify attributes and values that must be satisfied (DATE must be later than X, e.g.), or may require the performance of functions according to a specified script (IF DATE greater than X, THEN DO . . . , e.g.).
Upon the license evaluator 20 determining that the license 16 is valid and that the user satisfies the rules and requirements therein, the digital content 12 can then be rendered. In particular, to render the content 12, the decryption key (KD) is obtained from the license 16 and is applied to (KD(CONTENT)) from the content package 13 to result in the actual content 12, and the actual content 12 is then in fact rendered. The trusted component 18 may also need to verify and track dynamic aspects of the environment of the computing device 14 such as the application doing the content rendering.
Typically, to perform cryptographic functions in the connection with the trusted component 18, including the aforementioned applying of (KD) to (KD(content)) and all other cryptographic functions, the trusted component 18 has a black box 22. As with the license evaluator 20, the black box 22 is trusted in the DRM system 10 to carry out the wishes of the owner of the digital content 12 according to the rules and requirements in the license 16, and the user should not 0O be able to easily alter such trusted element for any purpose, nefarious or otherwise. It is also the job of the black box 22 to act as a license enforcer, and in particular to insure that content 12 is only decrypted and delivered to appropriate rendering code in the user's computing device 14.
Typically, the black box 22 can be expected to perform both symmetric (single key) and asymmetric (public-private key pair) cryptographic encryption and/or decryption. In particular, the aforementioned decryption key (KD) is typically a symmetric key and is therefore transmitted in an encrypted form by being encrypted by another symmetric key or a public key or private key. Thus, to decrypt (KD(content)), and if for example it is the case that (KD) is encrypted by a public key (PU) (i.e., (PU(KD))), the black box 22 must first obtain the private key (PR) corresponding to (PU) and asymmetrically apply (PR) to (PU(KD)) to result in (KD), and then must symmetrically apply (KD) to (KD(content)) to result in the content.
The black box 22 is provided with a secret and is entrusted to not reveal the secret to anybody or anything. Thus, the secret is the basis for encrypting the content key (KD), either directly or indirectly, and only the black box 22 as the bearer of the secret can decrypt the content key (KD). Thus, the license 16 having (KD) encrypted in a manner related to the secret is tied or bound to the black box 22 thereby. Typically, the secret is the private key (PR-BB) of a key pair (PU-BB, PR-BB) that is unique or nearly unique to the black box 22, and the corresponding public key (PU-BB) of the black box 22 is employed to encrypt (KD), either directly or indirectly. Of paramount importance, the black box 22 must be able to hide (PR-BB) and protect same and related cryptographic code from observation and tampering, and (PR-BB) and such code are therefore embedded or encapsulated in the black box 22, with appropriate obfuscation and self-protection.
In order to prevent unrestricted duplication, the black box 22 is tied to one particular hardware machine. Typically, such tying is achieved by hard coding machine properties into the black box 22 and authenticating such machine properties at run time. The black box 22 is also entrusted to cryptographically authenticate other software components, typically by verifying proffered digital signatures, and thus can ensure that other components of the trusted system 18 on the user's computing device 14 and that proffered items such as licenses 16 have not been tampered with.
Typically, each black box 22 is accompanied by a digital black box certificate 24z (FIG. 1A) bearing (PU-BB), a unique ID, a version number, and perhaps other certificate contents. The black box certificate 24z is thus tied to the black box 22 through the correspondence of (PU-BB) and (PR-BB). An issuer of a license 16 can decide to accept or reject a request for a license 16 from the trusted component 18 based on the certificate of the black box 22 thereof and the contents therein. In the event that a request is rejected, a newer black box 22 typically must be installed before the request is accepted. Of course, a new black box 22 may be installed for other reasons, may be initially installed separate from the installation of the remainder of the trusted component 18, may be installed with the remainder of the trusted component but not activated, etc.
As with other digital certificates, the black box certificate 24z is signed by a private key of an issuing entity (PR-ISSUER) based on a hash of at least a portion of the contents of the black box certificate 24z, and verifies by application of the corresponding public key (PU-ISSUER). If the contents are altered, the signature will not verify. Typically, the black box certificate 24z as issued by the issuer includes a chain 26 of certificates 24 leading back to a root certificate 24a from a trusted root authority, where each certificate in the chain 26 includes a public key that can be employed to verify the signature of the next certificate down the chain, and where the black box 22/trusted component 18 has knowledge of the public key of the root certificate 24 a. Thus, to verify the black box certificate 24z, the black box 22/trusted component 18 first verifies each certificate in the chain 26 from the root certificate 24a down to the black box certificate 24z. In addition, if any further certificate is issued based on the black box certificate 24z, i.e., is signed by (PR-BB), such further certificate can be verified by continuing the process down the chain to such further certificate.
More generally, it is to be appreciated that in addition to the black box certificate 24z, other certificates exist within the realm of the DRM system 10, where each certificate acts as a proffer that the corresponding element is authentic and trustworthy, holds a key, holds information relevant to the corresponding element, and/or the like. For example, an application to render content 12 may be accompanied by an application certificate 24aa and an accompanying chain 26 of certificates leading back to a trusted root authority recognized by the black box 22/trusted component 18. Likewise, a user participating in the DRM system 10 may be represented therein by a user certificate 24bb and an accompanying chain 26 of certificates leading back to a trusted root authority. Notably, a license 16 is a form of a certificate. Hence, as illustrated in the Figures, certificate 24 may represent a black box certificate 24z, a root certificate 24a, an issuer certificate 24x, or any other certificate in that chain (certificate a-x) an application certificate 24aa, user certificate 24bb, O/S certificate 24cc, computer certificate 24dd, license certificate 24ee, hardware certificate 24ff or any other suitable certificate.
Similarly, the computing device 14 may have a computing device certificate 24dd and accompanying chain 26, and various of the hardware elements (the hard drive, the processor, the video card, etc.) and software elements (the BIOS, the operating system, the graphics sub-system, etc.) within the computing device may each have a certificate 24ff and accompanying chain 26. Moreover, inasmuch as each license 16 is issued by an issuing entity and is signed, such license 16 is in a form of certificate 24ee and indeed has an accompanying chain 26 for purposes of verifying the signature thereof.
Typically, an entity that issues a particular certificate 24 has the power to revoke same by for example listing the public key associated with the certificate in an accessible revocation list. Thus, the black box 22/trusted component 18 in verifying any particular certificate 24 to authenticate the corresponding element may obtain from the issuer thereof a corresponding revocation list and review same to determine whether the certificate 24 is revoked, and if so may refuse to honor the certificate 24 and render rights-protected content 12 based on such revoked certificate 24. However, it is to be appreciated that when verifying/authenticating many certificates 24/elements from multiple issuers, as is the case with regard to the multiple chains 26 of certificates 24 seen in FIG. 1A, obtaining and reviewing revocation lists from all the issuers can quickly become cumbersome if not oppressive.
Accordingly, a need exists for a system and method to allow a trusted component 18, a black box 22, or any other inquiring entity to efficiently obtain and review such revocation lists in the course of authenticating and verifying certificates 24.